-
Notifications
You must be signed in to change notification settings - Fork 734
Update Python to 3.13.3 and add support to Windows on ARM64. #1477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
4662f05
to
eacc02c
Compare
eacc02c
to
eea63b9
Compare
I guess to perform that actual upload I should download this PR and run the update script? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm % comments
…packaging of pywin32 because it is no longer shipped via separate binary installers, but has migrated to use pip. Python 3.13.0 has bumped minimum macOS version to macOS 10.13
20a91ae
to
4094acb
Compare
Oh crud - I forgot to work through to land this. Updated this PR now to latest 3.13.3. @sbc100 would you be able to take a new look? Are you able to populate Google CDN with the needed zip artifacts? I presume those will have to be rolled first before landing this? |
If it helps, I can also generate the artifacts and upload them to my dev box for you to pull? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be arm64 instead of amd64 in the PR title?
scripts/update_python.py
Outdated
|
||
Raspberry Pi Debian 12 (Bookworm): | ||
1. Before calling this script, run "sudo apt install libssl-dev", or otherwise | ||
Python won't be able to use SSL. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why add these instruction about linux if this script is only designed to run on mac and windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I must say I don't remember anymore - I may have tried to make emsdk work on Linux on ARM as well, and given that Raspberry Pi was the only ARM Linux device I hard around, I probably used that... and then banged my head against trying to figure out what's going wrong with it.
I can delete this though.
Don't we need the macOS binaries too? |
Err, it totally should. :) Updated. |
Yeah, I can generate those in a moment. |
|
||
upload_base = 'gs://webassembly/emscripten-releases-builds/deps/' | ||
|
||
|
||
# Detects whether current python interpreter architecture is ARM64 or AMD64 | ||
# If running AMD64 python on an ARM64 Windows, this still intentionally returns AMD64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand the second part of this comment.
Do we really want to report AMD64
if we are running amd64 python on arm64 windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is important because if one is running an Intel x64 version of Python (e.g. under Rosetta on Mac), then pip
will install x64 versions of tools, not ARM64. So then the packager would accidentally pip install x64 versions of tools, but output an -arm64 artifact name.
So in terms of packaging, we should only report ARM64, if truly running on ARM64 version of the interpreter, to avoid any chance of mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, so effectively this script cannot cross build the arm64 python package.
I don't understand how that CI can be passing here... |
Oh, I needed to bump mininum macOS version from 10.13 to 11.0, or ctypes would no longer compile on x86 Apple Macs. 10.13 macOS supported: Laptops: MacBook (Late 2009 or later), MacBook Air (Late 2010 or later), MacBook Pro (Mid 2010 or later) Whereas 11.0 macOS requires at minimum: Laptops: MacBook (Early 2015 or later), MacBook Air (Mid 2013 or later), MacBook Pro (Late 2013 or later) At Unity we have required macOS 11.0 as the minimum target since Unity 2023.2 that was released in November 2023, for macOS for both Arm and x64 Macs. (macOS 11.0 was the first macOS version that shipped with Arm support) |
Does the CI run the update_python.py script? |
No, but I would expect them to try to download the latest SDK which should now be pointing a non-existent (at least not yet) python archives. Does |
"os": "win" | ||
}, | ||
{ | ||
"version": "main", | ||
"bitness": 64, | ||
"uses": ["python-3.9.2-64bit", "llvm-git-main-64bit", "node-20.18.0-64bit", "emscripten-main-64bit", "binaryen-main-64bit"], | ||
"uses": ["python-3.13.3-64bit", "llvm-git-main-64bit", "node-20.18.0-64bit", "emscripten-main-64bit", "binaryen-main-64bit"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, these are just the main
SDKs i think you need to also update the "releases-%releases-tag%
SDKs below. Then CI should fail.
Update Python to 3.13.0 and add support to Windows on AMD64. Rewrite packaging of pywin32 because it is no longer shipped via separate binary installers, but has migrated to use pip.